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1. Introduction 

This document is a preliminary external specification for a DOS 
3 type disk maintenance utility. This utility provides the 
functions of its DOS 2 counterpart, and provides two new 
functions which automatically verify or correct the structure 
of a disk. 

This version of the specification describes the disk 
verification process primarily, with the low level functions 
assumed to be very similar to their DOS 2 counterparts. Later 
versions of this specification will document the entire external 
interface. The term 'T.B.D.' indicates an item that is to be 
determined at a later phase of development. 


2. Verification processes 

The major effort involved with preparing this utility is the 
development of the verification process (CHECK command). The 
remainder of this section discusses the operation of that 
process. 


The verification process can be functionally segmented into 
several subprocesses, as shown below: 

Validation of the Volume I.D. 

Validation of the directories 

Validation of the individual files in the directories. 

Validation of the Bad Sector Table. 

Validation of the Sector Allocation Map. 

Although most of these subprocesses are independent, the 
validation of the Sector Allocation Map requires the cooperation 
of all of the other subprocesses. The technique used is to 
create a duplicate allocation map, which is initially empty, at 
the beginning of the process; this map is then updated as 
sectors are referenced by structural elements. At the end of 
the entire process, the duplicate map should be identical to the 
actual Sector Allocation Map, if there are no errors. 


2.1 Non-file processes 

The first parts of the disk structure to be validated are the 
general overhead structures that are present on all DOS 3 tyoe 
disks, and are independent of the actual files present on the 
disk. These structural elements include: 

Volume I.D. 

Sector Allocation Map (gross check). 

Bad Sector Table. 

Boot sector. 

Directories. 

The subsections that follow discuss the validation techniques 
that are to be used for each of these structural elements. 


2.1.1 Validation of Volume I.D. 
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Since all other structural elements of the disk are contained 
in (or pointed to by) the Volume I.D. sector (sector #4), it is 
important to validate this element first. If there is any 
chance that sector #4 of the disk being examined is not a valid 
Volume I.D., then the user is immediately informed and the 
process is suspended. 

The following tests are made in order to validate the Volume 

I. D. : 


VOLTYP (Volume Type byte) is tested for a value of $A5, 
only type currently defined; as additional volume types 
created, this utility should be modified to handle them. 
Theoretically, the latest version of the utility should 
to handle all DOS 3 volume types. 


the 

are 



be able 


VOLLAB (Volume Label) is written to the screen and is tested to 
see that it contains only ATASCII charcters in the range of $20 
through $7F. 


VOLDES (Volume Description) is written to the screen and is 
tested to see that it contains only ATASCII characters in the 
range of $20 through $7F. 

The numeric values of VOLMAX (Maximum Sector Number), VOLNAL 
(Number of sectors in allocation unit), VOLFLG (Volume Flags), 

VOLTRY (Volume Retry Count) and VOLOSN (O.S. Revision #) are 
written to the screen for operator verification. _ 

VOLTNS (Total Number of Sectors) and VOLNAB (VOLTNS/8) are 
checked to see that they are correctly derived from the value of 
VOLMAX. Where VOLTNS = (AA Q -L MAX + 7 - ) MOD 8 , ~ and VOT ^mB-^-VOLrT^_ 

" 7 ^“ 8 " s " C(C VolMAAt Morton L~i V VOCNJAO -o) is f B 4 =- 

VOLBM (Starting Sector of Sector Allocation Map) is c’rvecfe^ to^ - 

see that the sector number is not greater than the value of 

VOLMAX. 

VOLBMO (Sector Allocation Map Offset) is checked to see that the 
Sector Allocation Map does not improperly overlay another 
structural element. 

VOLBST (Starting Sector of Bad Sector Table) is checked to see 
that the sector number is not greater than the value of VOLMAX. 

VOLBSO (Bad Sector Table Offset) is checked to see that the Bad 
Sector Table does not improperly overlay another structural 
element. 


VOLOSS (O.S. Start Sector) is checked to see that it does not 
exceed the value of VOLMAX. 

VOLNOS (O.S. File Length) is checked to see that ... (T.B.D.). 

yOLNDR (Number of Directories) is checked to see that its value 
is between 1 and 16. 

Further checking of Volume I.D. elements is discussed in the 
remaining subsections of 2.1. 
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2 . 1.2 Validation of Sector Allocation Map 

A preliminary validation of the Sector Allocation Map is made to 
assure that allocations exist for the following structural 
elements (most of whose locations are defined in the Volume 

I.D.) : 


Volume I.D. sector itself (sector #4). 
Sector Allocation Map. 

Bad Sector Table. 

Di rectories (1-16). 

Boot sector (sector #1). 


2.1.3 Validation of Bad Sector Table 

The Bad Sector Table consists of pairs of sector numbers, all of 
which must not exceed the value of VOLMAX. The maximum number 
of entries in the map is contained in VOLNBS. 


2.1.4 Validation of Boot Sector 


The first six bytes of the Boot Sector will be validity checked 
as follows: 




BOOT FLAG (Byte 0) must be equal t© 
case, no further tests are made. 


0 2k. 


If this is not the 


BOOT LOAD ADDRESS (Bytes 2-3) is checked for ... T.B.D. 
INIT ADDRESS (Bytes 4-5) is checked for ... T.B.D. 


2.1.5 Validation of Directories & entries 

Each of the up to 16 Directory Descriptions are checked as 
described below: 

VDIFLG (Directory Flags) will be either $00 for an inactive 
directory or $01 for an active directory. The rest of the tests 
described in this subsection apply only to active directories. 

VDILBL (Directory Label) is written to the screen and tested to 
see that it contains only ATASCII characters in the range of 
$20 through $7F. 

VDISS (Directory Starting Sector) is checked to see that it does 
not exceed the value of VOLMAX. 

VDINS (Number of Sectors in Directory) is checked to see that 
its value is between 1 and xx (T.B.D.). 

Each of the up to 16 directories defined in the Volume I.D. is 
read and cnecked; the foliowing iterns are ex amined: 

Flags byte. 

File name/extension. 

File length. 

Segment pointers. 
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FILFLG (File Flags) is checked to see if a file exists for that 
entry; if not, the remaining tests are skipped. If the file 
exists but has not been properly CLOSED (OPO = 1), then ... 

r.B.D. ^ vC #^4^(fit | $$ 4 ^ 

FILNAM/FILEXT (File Name/Extension) are checked to see that the 
names consist only of ATASCII characters ranging from $20 
through $7F. 

FILLEN (File length) is checked to see that the file length 
specification does not exceed the size of the disk; the value of 
the length / 256 must not exceed the value of VOLMAX. The type 

must be Length - How eu.uA *.<k m!oc»WA * is 

FILSP1-2 (File Segment Pointers 1 - 2) are checked for validity 
by examining the 3 fields of each pointer: 

SPTYPE (Segment Pointer Type) must be one of the 3 valid 
types for a data segment pointer: Null, Block or EOF. 

SPSEC (Segment Starting Sector) must not exceed the valu p of 
VOLMAX. 

SPCNT (Segment Pointer Count) — SPSEC + SPCNT must not 
exceed the value of V^g^X. #!Wt *ktk 

FILSP3 (LINK SP) is checked for validity by examining the 3 
fields of the pointer: 

SPTYPE (Segment Pointer Type) must be one of the 2 valid 
types for a link segment pointer: Null or Link. If the type 
is Null, then the remaining tests are skipped. 

SPSEC (Segment Starting Sector) must not exceed the value of 
SPCNT (Segment Offset) must be equal to 4. 


2.1.6 Sector allocation 

As a structural element is examined , a check is made to see 
that the individual sectors which represent the element are all 
allocated in the Sector Allocation Map. In addition a check is 
made to see that the sectors are not yet allocated in the 
duplicate map; if they are, it indicates that two or more 
structural elements have sectors in common, a situation that is 
usually invalid. Note that some elements may have common 
allocation (the Sector Allocation Map and the Bad Sector Table 
may each overlap other structures) and will have to be treated 
specially. 


2.2 File processes 

Once the general overhead structures of the disk are validated, 
then the individual directory entries and the associated files 
may be validated. During this process the duplicate Sector 
Allocation Map is maintained; at the end of the file 
verification process the duplicate map should be identical to 
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the real map. The following tests are included in the fil^ 
validation process: 

All sector pointers valid. 

File length valid. 

All data and overhead sectors allocated properly. 


2.2.1 FSP #s 1 & 2 

Ihe Segment Pointers which were validated earlier per section 

? re now used to locate the data portion of the file The 
following conditions are tested for and reported if present: 

A Null type Segment Pointer found prior to an EOF type 
Segment Pointer. This condition probably indicates a file 
that was not closed properly. 

A Length or Link type Segment Pointer found. 


2.2.2 Link SP 


jpttqdU IT10re than two segments then the Link SP 

( ILSP3) of the directory entry for that file will point to a 
Segment Pointer Sector which will contain more segment 
e mitions and may in turn point to another Segment Pointer 
oector. This segment pointers within this structure must be 
enalyzed in the same manner as FSP Js 1 and 2. The followinq 
conditions are tested for and reported if present: 

A Link SP is defined and either FSP 1 or 2 was an EOF tvoe 
Segment Pointer. 


Neither FSP 1 nor 2 were an EOF type Segment Pointer and the 
Link SP is a Null type. 


The type of FILSP3 is other than Null or Link 

The backward Link Segment Pointer in a Segement Pointer 
Sector does not link back to its predecessor sector. 


2.2.3 Data portion 


Because there is absolutely no overhead or 
data portion of a file, there is no way to 
given data portion allocation belongs to a 
the single biggest deficiency in the DOS 3 
regards to integrity check and correction. 


redundancy in the 
determine whether a 
given file. This is 
files structure with 


2.2.4 File length 

The file length as specified in FILLEN (File Length) will be 
cnecked to see that is consistent with the file length as 
derived from the Block and EOF type Segment Pointers. 


2.2.5 File allocation 
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As a file is traversed, a check is made to see that the 

^fetors which represent the file are all allocated in 

that“t'n» A f locatlon Ma P- In addition a check is made to see 
that tne sectors are not yet allocated in the duplicate mao; if 

tney are, it indicates that two or more files have sectors'in 
common, a situation that is invalid. 

2.3 Final validation of Sector Allocation Map 

Once the non-file and file verification processes are complete, 
the duplicate Sector Allocation Map should be identical with the 
real Sector Allocation Map. Discrepancies would be due to one 
or more of the following conditions: 

a J 1 ? < ? at ^°[ 1 "■ hn allocat ion is contained in the mao which 
is not utilized by any structural element or file. 

Unallocated usage -- A structural element or file utilizes a 
disk area that has not been allocated. This will have been 
reported earlier, during the non-file and/or file validation 
processes. 


2.4 Medium validation 

The portions of the medium utilized within existing structures 
are ooviously validated in the earlier processes; however, as a 

* nal e ^ ch s L ector , on the disk is read and all read errors 

c.re catalogued. The Bad Sector Table is compared with the 
result of this test and any discrepancies are reported. 
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3. User interface 


3.1 Operating environment 

It is anticipated that the early versions will be menu driven 
and will be similar in operation to the DOS 2 file fix program. 
An option to have the program be command driven as well"as menu 
driven will be added later. 

3.2 Commands and options 

The following commands are available: 

CHECK -- Runs all of the tests described in section 2, but 
makes no attempts to correct any of the problems found. 

FIX -- Runs all of the tests described in section 2, and 
attempts to correct problems as they are found. 

DIRECTORY LISTING -- Displays all, or portions of, one or more 
of the directories on the disk. 

TRACE FILE ALLOCATION — Displays all of the sector numbers 
allocated for a specified file; the information is obtained from 
the file Segment Pointers. 

MODIFY DIRECTORY ENTRY -- Allows the operator to modify portions 
of a directory entry. 

SET DRIVE NUMBER -- Allows the operator to set the default disk 
drive number. 

RETURN TO DOS 


DISPLAY SECTOR (HEX, DECIMAL OR ATASCII) 


PATCH SECTOR (HEX, DECIMAL OR ATASCII) 


The following options are available 


flWi — 


VERIFY ON/OFF -- When FIX is running, this option determines 
whether operator verification is required for trivial fixes. 



Operator verification is always required for non-trivial fixes. 
The default value is ON. 


REPORT FULL/BRIEF/OFF — When CHECK or FIX is running, this 
option determines whether a progress report is generated, and if 
generated, whether it is to be a full report or a brief report. 
Errors are reported independently of this option. The default 
value is BRIEF. 


FILE TRACE ON/OFF -- When CHECK or FIX is running, this option 
determines whether an annotated trace of all disk sector 
references is generated. The default if OFF. 


SELECT REPORT DEVICE -- The default report device is the Screen 
Editor, but the report may be optionally output to any device 
other than the disk being tested. 
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NUMERIC RADIX -- The default number radix for all numbers read 
or written is hexadecimal, but the operator may change the radix 
to any value from 2 to 16. The radix specification itself is 
always in decimal notation. Thus binary is 2, octal is 8, 
decimal is 10, hexadecimal is 16, etc. Note that the reports 
are designed for hexadecimal reporting to a 38 character screen; 
hence some columnar data may not line up properly when using 
other notations, due to screen wrapping. 

BAD SECTOR SCAN ON/OFF -- The default case is to perform a bad 
sector scan as part of a CHECK or FIX command. This operation 
may optionally be eliminated. 

ou>^$secro&. *- 

3.3 Messages and responses 

This section lists most of the anticipated messages that will be 
generated by the program; the messages that are being brought 
forward from the DOS 2 disk fixer are not shown here at this 
writing (they will appear in later versions of this document). 


3.3.1 Normal 

One class of messages is generated as a reporting function to 
allow.the user to follow the progress of a given command. These 
messages are summarized below, along with an indication as to 
whether they are part of the BRIEF or FULL report: 


VOLUME '11111111' TYPE tt SECTORS sss ‘ BRIEF/FULL/OFF 

This message is written at the beginning of any command. 

Where: 1 is the volume label (VOLLAB). 

t is the volume type (VOLTYP). 

s is the number of sectors on the disk (VOLMAX). 


DESCR 'dddddddddddddddddddddddddddddd' FULL 

This message is written at the beginning of any command. 
Where: d is the volume description (VOLDES). 


SECTOR ALLOCATION MAP AT aaa/oo FULL 

BAD SECTOR TABLE AT bbb/oo nn 

DIRECTORY 1 AT ddd nn 

DIRECTORY 2 AT ddd nn 

etc. 

* 

This message is written during the Volume I.D. validation phase. 

Where: a is the starting sector for the Sector Allocation Map. 
o is the sector offset. 

n is the number of entries (max) for the element, 
b is the starting sector for the Bad Sector Table, 
d is the starting sector for a Directory. 
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DIRECTORY nn '11111111' BRIEF 

Tnis message is written prior to the examination of each disk 
directory entry. 

Where: n is the directory number (1-16 by position). 

1 is the directory label (VDILBL). 


DIRECTORY nn '11111111' FULL 

FLAG ff START sss SECTORS qqq 

This message is written prior to the examination of each disk 
directory entry. 

Where: n is the directory number (1-16 by position). 

1 is the directory label (VDILBL). 
f is the flag byte value (VDIFLG). 

s is the starting sector for the directory (VDISS). 
q is the number of sectors in the directory (VDINS). 


FILE 'nnnnnnnnnnnn.eee' FLAG ff FULL 

This.message is written prior to the examination of each file 
within a directory. 

Where: n is the file name (FILNAM) . 

e is the file extension (FILEXT). 
f is the file flag byte (FILFLG). 


FSP 1 TYPE tt SECTOR sss COUNT nnn TRACE 

FSP 2 TYPE tt SECTOR sss COUNT nnn 

LINK SP tt SECTOR sss OFFSET oo 

SP TYPE tt SECTOR sss COUNT nnn 

etc. 

This message is written during the validation of the file 
structure if the FILE TRACE option is ON (CHECK or FIX), or 
during the execution of the TRACE FILE ALLOCATION command. 

Where: t is the Segment Pointer type, 
s is the sector number, 
n is the sector count, 
o is the link offset. 


BOOT SECTOR: FLAG ff SECTORS nn FULL 

LOAD ADDR 1111 INIT ADDR iiii 

xhis message is written at the time the Boot Sector is 
validated. 


Where: 


f is the 
n is the 
1 is the 
i is the 


flag byte. 

number of consecutive boot sectors, 
load address, 
initialization address. 
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FREE SECTORS sss BRIEF/FULL/OFF 

This message is written at the end of a CHECK or FIX operation. 
Where: s is the number of unallocated sectors on the disk. 


BAD SECTORS ssss/mmmm ssss/mmmm ... BRIEF/FDLL/OFF 

This message is written at the end of a CHECK or FIX operation; 
the information is obtained from the Bad Sector Table. 

Where: s is the number of a known bad sector. 

m is the corresponding good sector to which it is mapped. 


3.3.2 Error 

Another class of messages is generated only upon detection of an 
anomoly in the disk structure. These messages are summarized 
below: 


CAN'T PROCESS VOLUME TYPE tt 

This message is generated if the volume type is not one that can 
be processed by the CHECK or FIX commands; the process will 
suspend itself. 

Where: t is the volume type (VOLTYP). 


INVALID SECTOR POINTER FOR vvvvvv SECTOR sss 

This message is written whenever a sector pointer data type has 
an out of range value (greater than the value of VOLMAX). 

Where: v is the symbolic name for the variable in question, 
s is the value of the sector number in question. 


VARIABLE vvvvvv OUT OF RANGE: IS iii S/B rr xxx 

This message is written whenever a variable has an out of range 
value. 

Where: v is the symbolic name for the variable in question, 
i is the value in question, 
r is a relation operator (< > = etc.), 
x is the expected value or limit. 


TEXT CONTAINS INVALID CHARACTERS 

This message is written whenever a text field is encountered 
which contains invalid ATASCII characters (not in the range of 
$20 through $7F) . 


PRIOR ALLOCATION FOR SECTOR sss 
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This'message is written whenever a structural or file element is 
encountered which utilizes a sector which has already been 
allocated by another element. 

Where: s is the sector in question. 


NO ALLOCATION FOR SECTOR sss 

This message is written whenever a structural or file element is 
ecountered which is not currently allocated. 

Where: s is the sector in question. 


MISMATCH BETWEEN ACTUAL ALLOCATION 
MAP AND COMPUTED ALLOCATION MAP, 

REPLACE WITH COMPUTED MAP (Y/N)? 

This message is generated at the end of the FIX process whenever 
the duplicate allocation map is not identical with the Sector 
Allocation Map. 


READ ERROR ee SECTOR sss 

This message is generated whenever a disk read error is 
encountered. The program will attempt to reread up to 3 times 
before giving up. 

Where: e is the error status returned by CIO. 
s is the sector number. 


LINK SP MISMATCH ppp sss 

This message is generated whenever a mismatch is found between 
the backward Link SP of a Segment Pointer Sector (s) and the 
forward Link SP of its predecessor (p). 


4. Limitations 

The primary limitation in the current design is the inablity to 
determine the true ownership of a file data sector where there 
are multiple claims via Block or EOF Segment Pointers. The 
problem might be resolved by adding some form of redundant 
information to the FMS disk structure, but the nature of such 
information has not yet been identified. The DOS 1 structure 
was well covered in this area, having both a file relative 
record number and a file identifier within every data sector. 
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